Systems and methods for secure communications in vehicle telematics systems

ABSTRACT

A vehicle telematics system is provided having secure communication capabilities between a vehicle telematics device and external computing devices. In one embodiment, the vehicle telematics device includes a processor; a memory coupled to the processor and storing a vehicle telematics application; and a security chip coupled to the processor and the memory, wherein the security chip is configured to support a Transport Layer Security (TLS) stack.

CROSS-REFERENCE TO RELATED APPLICATIONS

This non-provisional United States (U.S.) patent application claims thebenefit of U.S. Provisional Patent Application No. 62/481,437 entitledSYSTEMS AND METHODS FOR SECURE COMMUNICATIONS IN VEHICLE TELEMATICSSYSTEMS filed on Apr. 4, 2017 by inventor Peter Hergesheimer,incorporated herein by reference.

FIELD

The embodiments generally relate to secure data communication of data bywireless networks.

BACKGROUND

Telematics is the integrated use of telecommunications and informatics.Telematics units are installed in vehicles to provide a variety oftelematics functionality in the vehicle. This functionality includes,but is not limited to, emergency warning systems, navigationfunctionality, safety warnings, and automated driving assistance.Telematics units are also capable of recording data related to theoperation of the vehicle and providing that information for analysis,whether in real-time or during a time when the vehicle is beingserviced. This information can be used in a variety of applications,such as fleet tracking, shipment tracking, insurance calculations, andin vehicle management and service.

A Global Positioning System (GPS) is a space-based global navigationsatellite system that utilizes a network of geo-synchronous satellitesthat can be utilized by a GPS receiver to determine its location. Manytelematics systems incorporate a Global Positioning System (GPS)receiver that can be used to obtain the location of a vehicle at acertain measured time. Using the signals received by the GPS receiver,the heading information of the vehicle can be determined. A GPS receivercan determine velocity information in a variety of ways including, butnot limited to, measuring the Doppler shift of the received signals andby comparing the location of a vehicle at a plurality of measured times.The acceleration of the vehicle can be determined as the change in speeddivided by the time between the measurements. A GPS receiver's abilityto determine acceleration can be limited due to the dependence of themeasurement upon factors such as, but not limited to, reception andsatellite availability. In addition to location information, a GPSreceiver can also be configured to provide time data. However,measurements determined via a GPS receiver can contain errors thataffect the accuracy of the measured information. In particular, GPSsignals are vulnerable to signal delays, inconsistencies of atmosphericconditions that affect the speed of the GPS signals as they pass throughEarth's atmosphere, and multipath distortions. Additionally, otherfactors not listed can influence GPS signals and result in measurementerrors.

BRIEF SUMMARY

The embodiments are best summarized by the claims included herein.Briefly, systems and methods for secure communications in vehicletelematics systems in accordance with the embodiments are disclosed.

BRIEF DESCRIPTIONS OF THE DRAWINGS

FIG. 1 is a conceptual illustration of a vehicle telematics system inaccordance with an embodiment.

FIG. 2A is a conceptual illustration of a vehicle telematics device inaccordance with an embodiment.

FIG. 2B is a conceptual illustration of another vehicle telematicsdevice in accordance with an embodiment.

FIG. 3 is a chart showing example threat descriptions and correspondingsecurity risk levels.

FIG. 4 is a conceptual block diagram of a vehicle telematics systemhaving existing security (e.g., base level security).

FIG. 5 is a conceptual block diagram of a vehicle telematics systemhaving Level-1 security (e.g., enhanced access protection).

FIG. 6 is a conceptual block diagram of a vehicle telematics systemhaving level-2 security (e.g., full TLS).

FIG. 7 is a tree diagram showing a public key infrastructure (PKI) forthe vehicle telematics system, which has level-2 security.

FIG. 8 is a conceptual block diagram of a system for provisioning avehicle telematics system having level-2 security.

FIG. 9 is a chart showing example mitigation techniques for variousthreat descriptions and corresponding security risk levels.

DETAILED DESCRIPTION

In the following detailed description of the embodiments, numerousspecific details are set forth in order to provide a thoroughunderstanding. However, it will be obvious to one skilled in the artthat the embodiments may be practiced without these specific details. Inother instances, well known methods, procedures, components, andcircuits have not been described in detail so as not to unnecessarilyobscure aspects of the embodiments.

The embodiments include a method, an apparatus, and a system for securecommunications in vehicle telematics systems. Many vehicles are equippedwith a telematics unit. These telematics units can obtain and/or measurea variety of data regarding the conditions and/or location of thevehicle along with receiving and transmitting data to remote serversystems. In order to facilitate these communications, the telematicsunits can include a radio transceiver, such as a cellular modem, whichcan be utilized to communicate with the remote server systems. However,these radio transceivers require a data plan or other cellular servicespecifically dedicated to the telematics unit. Additionally, manytelematics units are only compatible with one service provider (e.g.cellular service provider), thereby requiring different versions of thetelematics unit for different geographic regions and limiting theability of a particular telematics unit to be utilized in all locationsin which a particular vehicle may travel.

In a variety of embodiments, the operational state of a vehicle isutilized to determine if a vehicle telematics device should transmitand/or receive data. In a number of embodiments, vehicle ignition state(i.e. the operational status of the vehicle) is ascertained bymonitoring the vehicle for signs indicative of the vehicle ignitionstate without directly connecting to the vehicle ignition line.Information indicative of vehicle ignition state (i.e. vehicle statusdata) can be ascertained by observing characteristics of the vehicleincluding but not limited to the power supplied by the vehicle, vehiclevibration, communications on an OBD II port (e.g., on-board diagnosticsconnector) or other vehicle data bus line, and/or vehicle positioninformation. In many embodiments, multiple different types ofinformation are combined to ascertain the vehicle ignition state.Systems and methods for using an asset tracking device added to thevehicle after the manufacture of the vehicle without a direct connectionto the vehicle ignition line that can be utilized to determine ignitionstate information in accordance with embodiments are described in U.S.Pat. No. 8,489,271, titled “Systems and Methods for Virtual IgnitionDetection” and issued Jul. 16, 2013, the disclosure of which is herebyincorporated by reference in its entirety.

Systems and methods for radio access interfaces in accordance withembodiments are further described in more detail herein.

Vehicle Telematics Systems

Vehicle telematics systems in accordance with embodiments can transmit avariety of data between a remote server system and a vehicle telematicsdevice using a mobile communications device. A conceptual diagram of avehicle telematics system 100 in accordance with an embodiment is shownin FIG. 1. The vehicle telematics system 100 includes one or morevehicle telematics devices (110, 110′, etc.). The vehicle telematicsdevice 110 can communicate with a mobile communications device 116, avehicle data bus 112, and/or an input/output (I/O) interface 114 asappropriate to the requirements of specific applications of embodiments.

In a variety of embodiments, the mobile communications device 116 and/orthe vehicle telematics device 110 communicates with the remote serversystem 130 via a network 120. The vehicle telematics device 110′ mayinclude the mobile communications device 116 to communicate to theremote server system 130 over the network 120. Otherwise, the vehicletelematics device 110 can be coupled in communication with the mobilecommunications device 116 in order for the vehicle telematics device 110to communicate with the remote server system 130 over the network 120.

In a variety of embodiments, the network 120 is the Internet. In manyembodiments, the network 120 is any wired or wireless network, such as acellular network, between the vehicle telematics device 110′ and/or themobile communications device 116 and the remote server system 130. In anumber of embodiments, the remote server system 130 is implemented usinga single server system. In several embodiments, the remote server system130 is implemented using multiple server systems.

In a variety of embodiments, the vehicle telematics device 110 isinstalled in a vehicle having a vehicle data bus 112. In severalembodiments, the vehicle telematics device 110 is connected to a vehiclediagnostic connector that provides access to the vehicle data bus 112.The vehicle telematics device 110 can obtain data from any of a varietyof vehicle devices connected to the vehicle data bus 112 utilizing anyof a variety of techniques as appropriate to the requirements ofspecific applications of embodiments. Vehicle devices can include, butare not limited to, engine sensors, electronic control unit (ECU)devices, alternator sensors, vibration sensors, voltage sensors, oxygensensors, Global Positioning System (GPS) receivers, ignition devices,weight sensors, wireless network devices, and/or accelerationdetermination devices. Systems and methods for connecting to a vehicledata bus that can be utilized in accordance with embodiments aredescribed in SAE J1978, titled “OBD II Scan Tool,” first published bySAE International of Troy, Mich. on Mar. 1, 1992 and last updated Apr.30, 2002. Systems and methods for obtaining data from devices connectedto a vehicle data bus are described in SAE J1979, titled “E/E DiagnosticTest Modes,” first published by SAE International on Dec. 1, 1991 andlast updated Aug. 11, 2014. The disclosures of SAE J1978 and SAE J1979are hereby incorporated by reference in their entirety. In a number ofembodiments, the vehicle telematics device 110 is connected directly,either wired or wirelessly, to one or more sensors within the vehicleand/or does not utilize the vehicle data bus 112.

The vehicle telematics device 110 can include any of a variety ofsensors and/or devices, including those described herein with respect tothe vehicle data bus and any described in more detail herein, to obtaindata regarding the status of the vehicle. The vehicle telematics device110 can also communicate with any of a variety of sensors and/or devicesusing the I/O interface 114. The I/O interface 114 can be anyconnection, including wired and wireless connections, as appropriate tothe requirements of specific applications of embodiments. In severalembodiments, the vehicle telematics device 110 can execute scripts toread data and/or perform particular processes. These scripts can bepre-loaded on the device and/or obtained from the remote server system130, vehicle data bus 112, and/or the I/O interface 114 as appropriateto the requirements of specific applications of embodiments. The vehicletelematics device 110 can be self-powered and/or connected into theelectrical system of the vehicle in which the vehicle telematics device110 is installed. In a variety of embodiments, the vehicle telematicsdevice is powered via the vehicle data bus 112 and/or the I/O interface114. In many embodiments, the vehicle telematics device 110 utilizes aGlobal Positioning System (GPS) receiver in order to determine thelocation, speed, and/or acceleration of the vehicle. In severalembodiments, the vehicle telematics device 110 obtains location datafrom the mobile communications device 116. However, it should be notedthat any location-determining techniques, such as cellular towertriangulation, wireless network geolocation techniques, and deadreckoning techniques, could be utilized as appropriate to therequirements of specific applications of embodiments.

In a variety of embodiments, the vehicle telematics device 110, mobilecommunication device 116, and/or remote server system 130 provides auser interface allowing for visualizing and interacting with the datatransmitted and/or received between the systems. In several embodiments,the vehicle telematics device 110, mobile communications device 116,and/or remote server system 130 provides an interface, such as anapplication programming interface (API) or web service that providessome or all of the data to third-party systems for further processing.Access to the interface can be open and/or secured using any of avariety of techniques, such as by using client authorization keys, asappropriate to the requirements of specific applications.

Although a specific architecture of a vehicle telematics system inaccordance with embodiments are discussed with reference to FIG. 1, avariety of architectures, including sensors and other devices andtechniques not specifically described herein, can be utilized inaccordance with embodiments. Furthermore, the processes described hereincan be performed using any combination the vehicle telematics device,mobile communications device, and/or the remote server systems asappropriate to the requirements of specific applications of embodiments.

Vehicle Telematics Devices

Vehicle telematics devices in accordance with embodiments can transmitand receive data via a mobile communications device. A conceptualillustration of a vehicle telematics device in accordance with anembodiment is shown in FIG. 2A. The vehicle telematics device 110includes a processor 210 and a security chip 215 in communication withmemory 230. The vehicle telematics device 110 can also include one ormore communication interfaces 220 capable of sending and receiving data.In a number of embodiments, the communication interface 220 is incommunication with the processor 210, the security chip 215, the memory230, and/or the sensor device(s) 240. In several embodiments, the memory230 is any form of storage configured to store a variety of data,including, but not limited to, a vehicle telematics application 232,sensor data 234, and telematics data 236. In many embodiments, thevehicle telematics application 232, sensor data 234, and/or telematicsdata 236 are stored using an external server system and received by thevehicle telematics device 110 using the communications interface 220.

Sensor devices 240 can include RPM sensors, voltage sensors, GPSreceivers, noise sensors, vibration sensors, acceleration sensors,weight sensors, and any other device capable of measuring data regardinga vehicle as appropriate to the requirements of specific applications ofembodiments. Sensor devices 240 can be included within the vehicletelematics device 110 and/or located external to the vehicle telematicsdevice 110. The vehicle telematics device 110 can communicate withexternal sensor devices using the communications interface 220, such asvia a vehicle data bus, I/O interface (including serial interfaces),mobile communications device 116, and/or a network connection asappropriate to the requirements of specific applications of embodiments.In a variety of embodiments, the vehicle telematics device 110 isconnected to a diagnostic connector (e.g., an OBD II port) in a vehicle.The vehicle telematics device 110 can also communicate with the remoteserver system 130 through the communications interface 220 and a mobilecommunications device 116 over the network 120.

FIG. 2B is a conceptual illustration of the vehicle telematics device110′ in accordance with an embodiment. The vehicle telematics device110′ includes the mobile communications device 116 coupled to thecommunications interface 220 to communicate with the remote serversystem 130 over the network 120.

The vehicle telematics application 232 can direct the processor 210and/or the security chip 215 to perform a variety of securecommunication processes, a number of which that can be performed inaccordance with embodiments further described herein.

Although specific architectures for vehicle telematics devices inaccordance with embodiments are conceptually illustrated in FIG. 2A, anyof a variety of architectures, including those that store data orapplications on disk or some other form of storage and are loaded intomemory at runtime, can also be utilized. Additionally, any of the datautilized in the system can be cached and transmitted once a networkconnection (such as a wireless network connection via the communicationsinterface) becomes available. In a variety of embodiments, a memoryincludes circuitry such as, but not limited to, memory cells constructedusing transistors, that are configured to store instructions. Similarly,a processor can include logic gates formed from transistors (or anyother device) that dynamically perform actions based on the instructionsstored in the memory. In several embodiments, the instructions areembodied in a configuration of logic gates within the processor toimplement and/or perform actions described by the instructions. In thisway, the systems and methods described herein can be performed utilizingboth general-purpose computing hardware and by single-purpose devices.

Secure Communications

FIG. 3 is a chart 300 showing example threat descriptions 305 andcorresponding security risk levels 310. Example threat descriptions 305having a security risk level 310 of “critical” include at least thefollowing: Over-the-Air (OTA) updates that are not encrypted or signed,OTA updates that are initiated without authentication, communicationssecurity (COMSEC) having no end-to-end encryption, man-in-the-middle(MITM) attack (especially on Global System for Mobile Communications(GSM)), and a Short Message Service (SMS) interface that is notauthenticated (e.g., subject to MITM attacks).

Example threat descriptions 305 having a security risk level 310 of“high” include at least the following: Domain Name System (DNS) spoofing(e.g., communication sent to wrong server) and information disclosure inan Assisted Global Positioning System (A-GPS) component. The vehicletelematics system 100 may undergo other threats not shown in FIG. 3.

In the vehicle telematics system 100 of FIG. 1, a primary securitythreat is remote access by an external computing device. For example, anexternal computing device might attack the vehicle telematic system 100according to one of the threat descriptions 305 listed in FIG. 3. Thereare at least three levels of security protection to address a primarythreat: existing security (e.g., readily available or base levelsecurity), Level-1 security (e.g., enhanced access protection), andlevel-2 security (e.g., full Transport Layer Security (TLS)). Asecondary (non-primary) threat is physical access to the vehicletelematics system 100.

FIG. 4 is a conceptual block diagram of a vehicle telematics system 400having existing security (e.g., base level security). The vehicletelematics device 110 can communicate with a maintenance server 434, acustomer server 432, and/or the mobile communications device 116. Thecommunication by the vehicle telematics device 110 with servers or otherdevices can be performed with various protocols, such as transmissioncontrol protocol (TCP)/internet protocol (IP) and/or user datagramprotocol (UDP)/internet protocol (IP) for example.

The vehicle telematics device 110 sends inbound encrypted data to acustomer server 432. The inbound encryption provides interceptprotection (e.g., protection from an interception attack) on datagenerated by the vehicle telematics device 110. The vehicle telematicsdevice 110 and/or the customer server 432 stores a cryptographic key(e.g., public encryption key and/or private decryption key) as aconfiguration parameter.

The customer server 432 sends password authentication to access thevehicle telematics device 110. The password authentication providesremote access protection (e.g., protection from a remote access attack).The vehicle telematics device 110 and/or the customer server 432 storespassword authentication as a configuration parameter.

The mobile communications device 116 sends an SMS password to thevehicle telematics device. The SMS password provides remote accessprotection (e.g., protection from a remote access attack). The vehicletelematics device 110 and/or the mobile communications device 116 storesSMS password authentication as a configuration parameter.

The vehicle telematics device can receive an attention (AT) commandpassword from a local device (e.g., local terminal program). The ATcommand password provides local access protection (e.g., protection froma malicious user). The AT command password is typically the samepassword as the SMS password.

FIG. 5 is a conceptual block diagram of a vehicle telematics system 500having Level-1 security (e.g., enhanced access protection). The vehicletelematics device 110 can communicate with the maintenance server 434,the customer server 432, and/or the mobile communications device 116.

The vehicle telematics device 110 can send an encrypted inbound messageto a customer server 432. The encryption provides intercept protection(e.g., protection from an interception attack) on data generated by thevehicle telematics device 110. The vehicle telematics device 110 and/orthe customer server 432 stores cryptographic keys and settings asconfiguration parameters. To the portions of an inbound message, thevehicle telematics device 110 can apply the encryption to the payloadand vehicle identification number (VIN) in an option header. Acryptographic key is based on a proprietary stream cipher. The vehicletelematics device 110 typically does not apply encryption to themaintenance server interface.

The customer server 432 can send authenticated outbound messages to oneor more vehicle telematics devices 110. The outbound authenticationprotects authenticity and integrity of messages that the customer server432 sends to the vehicle telematics devices 110. To authenticate anoutbound message, the sender (e.g., customer server 432) calculates adigital signature of the message combined with a secret key. Theauthentication code or signature is calculated by using the entiremessage (e.g., options, header, payload, etc.). To authenticate outgoingmessages, the customer server 432 can use, for example, keyed-hashmessage authentication code Merkle-Damgård hash function 5 (HMAC-MD5),16-byte digest. The secret authentication keys used in the messageauthentication are unique to each vehicle telematics device 110 and eachinterface (e.g., inbound interface, maintenance interface at the vehicletelematics device 110, etc.). The sender (e.g., customer server 432)sends the signature along with the message. The receiver (e.g., vehicletelematics device 110) of the message authenticates the message byverifying the digital signature that is sent with the message matches asignature that the receiver calculates by using the received messagecombined with the secret key.

The maintenance server 434 and/or the customer support server 432 canauthenticate files transmitted to one or more vehicle telematics devices110. The file authentication provides file tampering protection byvalidating authenticity and integrity of files using a digital signatureof the file transmitted along with the file. The maintenance server 434and/or the customer support server 432 applies file authentication toall files transmitted to the vehicle telematics device 110. Themaintenance server 434 and/or the customer support server 432 supportsthe file authentication protocol. To authenticate files, the maintenanceserver 434 can use, for example, an RSA Security/Secure Hash Algorithmtwo hundred and fifty-six (RSA/SHA-256) digital signature algorithm. Thecryptographic keys used by the vehicle telematics device 110 to validatethe digital signature of the file can be embedded in the software codeof the vehicle telematics device 110.

The mobile communications device 116 can authenticate SMS messages fortransmission to the vehicle telematics device 110. The SMSauthentication provides remote access protection (e.g., protection froma remote access attack). The mobile communications device 116 and thevehicle telematics device 110 can handle the SMS authentication. In oneembodiment, SMS authentication is substantially the same as messageauthentication (e.g., HMAC-MD5), which is discussed with reference toFIGS. 4 and 5. Accordingly, the SMS authentication includes use of acryptographic key that is similar to a cryptographic key used in messageauthentication. SMS authentication can complicate SMS access at themobile communications device 116 and/or the vehicle telematics device110. Accordingly, a software application to handle SMS authenticationmay be required to be loaded onto the mobile communications device 116and onto the vehicle telematics device 110.

The customer server 432 can generate authentication keys from a seed(e.g., some non-secret value) and an electronic serial number (ESN) ofthe vehicle telematics device 110. For example, the customer server 432can provide and manage a seed and an authentication key for each foreach vehicle telematics device 110. Each vehicle telematics device 110can generate a seed and an authentication key for each interface at thevehicle telematics device 110.

In one embodiment, protection can be enabled remotely but cannot bedisabled remotely. For example, the mobile communications device 116,the customer server 432, and/or the maintenance server 434 can remotelyenable protected communication with the vehicle telematics device 110.However, neither the mobile communications device 116, the customerserver 432, nor the maintenance server 434 can remotely disableprotected communication with the vehicle telematics device 110.

FIG. 6 is a conceptual block diagram of a vehicle telematics system 600having level-2 security (e.g., full TLS). The vehicle telematics device110 can communicate with the maintenance server 434, the customer server432, and/or the mobile communications device 116.

The customer server 432 and/or the maintenance server 434 cancommunicate (e.g., transmit data) with the vehicle telematics device 110via transmission control protocol (TCP)/transport layer security (TLS)session security. For example, the devices of the vehicle telematicssystem 600 can support TLS for TCP and hypertext transfer protocol(HTTP). The devices of the vehicle telematics system 600 do not haveuser datagram protocol (UDP) support. The TCP/TLS session securityprovides protection via authentication and encryption. The vehicletelematics system 600 applies the TCP/TLS session security to allinternet protocol (IP) interfaces (e.g., inbound interface, maintenanceinterface, etc.). The TCP/TLS session security uses public-keycryptography with public key infrastructure (PKI) certificates.

Like Level-1 security of FIG. 4, the maintenance server 434 and/or thecustomer support server 432 in FIG. 5 can also authenticate filestransmitted to one or more vehicle telematics devices 110. The fileauthentication provides file tampering protection by validatingauthenticity and integrity of files using a digital signature of thefile transmitted along with the file. The maintenance server 434 and/orthe customer support server 432 applies file authentication to all filestransmitted to the vehicle telematics device 110. The maintenance server434 and/or the customer support server 432 supports the fileauthentication protocol. To authenticate files, the maintenance server434 can use a digital signature algorithm, for example, an RSASecurity/Secure Hash Algorithm two hundred and fifty-six (RSA/SHA-256)digital signature algorithm. The cryptographic keys used by the vehicletelematics device 110 to validate the digital signature of the file canbe embedded in the software code of the vehicle telematics device 110.

Like Level-1 security of FIG. 4, the mobile communications device 116 inFIG. 5 can also authenticate SMS messages for transmission to thevehicle telematics device 110. The SMS authentication provides remoteaccess protection (e.g., protection from a remote access attack). In oneembodiment, SMS authentication is substantially the same as messageauthentication (e.g., HMAC-MD5), which is discussed with reference toFIGS. 4 and 5.

FIG. 7 is a tree diagram showing a public key infrastructure (PKI) 700for the vehicle telematics system 600, which has level-2 security. ThePKI 700 shows how the vehicle telematics system 600 of FIG. 6 managessecurity certificates. A certificate authority or certificationauthority (CA) is a third-party computing device that issues digitalcertificates. A digital certificate certifies the ownership of a publicencryption key by the named subject of the certificate. This allowsother parties to rely upon signatures or on assertions made about theprivate decryption key that corresponds to the certified publicencryption key. A certificate authority acts as a trusted third partythat is trusted both by the subject (owner) of the certificate and bythe party relying upon the certificate.

A main certificate authority 705 signs end-point certificate authoritycertificates for the vehicle telematics system 600, including one ormore mobile telematics devices 110, the maintenance server 434, thecustomer server 432, and another customer server 715. The maincertificate authority 705 signs a customer certificate authority 710 forthe customer server 715. Computing devices in the telematics system 600exchange certificate authority certificates during TLS sessionnegotiations. Computing devices in the telematics system 600 can installdevice certificates and/or certificate authority certificates by using,for example, authenticate-then-encrypt (AtE).

FIG. 8 is a conceptual block diagram of a system 800 for provisioning avehicle telematics system 600 having level-2 security. The systemincludes, without limitation, automatic test equipment (ATE) 805, avehicle telematics device 110, and a main certificate authority 705. Thesystem 800 typically performs provisioning in, for example, a factoryand offline from the vehicle telematics system 600.

The vehicle telematics device 110 uses the security chip 215 to generatea public-private cryptographic key pair. The vehicle telematics device110 can securely store the private cryptographic key. The vehicletelematics device 110 combines a customer identity provided by the ATE805 with the public cryptographic key to generate a certificate signingrequest (CSR) for the vehicle telematics device 110. The customeridentity is optional security that ensures the vehicle telematics device110 will only connect with the correct customer server 715. The ATE 805passes the CSR to the main certificate authority 705. The maincertificate authority 705 signs the authentication certificate. Onto thevehicle telematics device 110, the system 800 loads (1) the signedauthentication certificate for the telematics device 110 and (2) a copyof the certificate authority's own certificate or certificates signed bythe main certificate authority 705. The vehicle telematics device 110securely stores the signed authentication certificates in the securitychip 215.

FIG. 9 is a chart 900 showing example mitigation techniques 905 forvarious threat descriptions 305 and corresponding security risk levels310. The threat descriptions 305 and corresponding security risk levels310 are discussed with reference to FIG. 3. The vehicle telematicssystem 100 may undergo other threats not shown in FIG. 9. To mitigateOver-the-Air (OTA) updates that are not encrypted or signed, the vehicletelematics system 100 may include file authentication (e.g., level-1security and level-2 security). To mitigate OTA updates that areinitiated without authentication, the vehicle telematics system 100 mayinclude direct message authentication (e.g., level-1 security andlevel-2 security). To mitigate communications security (COMSEC) havingno end-to-end encryption, the vehicle telematics system 100 may encryptdata at the vehicle telematics device 110 (e.g., base level security andlevel-1 security). The vehicle telematics system 100 may alternativelyencrypt data at all end points, including the vehicle telematics device110, the customer server 432, and the maintenance server 434 (e.g.,level-2 security). To mitigate man-in-the-middle (MITM) attack(especially on Global System for Mobile Communications (GSM)), thevehicle telematics system 100 may include direct message authentication,file authentication, message encryption, and file encryption (e.g.,level-1 security and level-2 security). To mitigate Short MessageService (SMS) interface that is not authenticated (e.g., subject to MITMattacks), the vehicle telematics system 100 may SMS authentication(e.g., level-1 security and level-2 security). To mitigate Domain NameSystem (DNS) spoofing (e.g., communication sent to wrong server), thevehicle telematics system 100 may include server authentication (e.g.,level-2 security). To mitigate information disclosure in an AssistedGlobal Positioning System (A-GPS) component, the vehicle telematicssystem 100 may randomize the GPS position in an AGPS request associatedwith the vehicle telematics device 110.

Practical Implementation Considerations

Level-2 TLS requires some important implementation considerations.Operations of a TLS stack require additional and sufficient memoryresources (e.g., 30 kilobytes of RAM, 100 kilobytes of flash memory). Asecurity stack is a group of software/firmware programs that work intandem to produce a result or achieve a common goal (e.g., a goal ofconfiguring a processor to carry out security operations). Sufficientmemory for a TLS stack is unavailable in typical commercial products(e.g., typical vehicle telematics devices).

In one embodiment, a vehicle telematics device requires the addition ofhardware, such as security chip 215 of FIG. 2A. The security chip 215may be included on an add-on security processor board and is enabled tosupport a security stack (e.g., TLS stack). Alternatively, a securitystack can be integrated into the processor 210.

In one embodiment, the processor 210 is upgraded to have more RAM andmore hardware cryptography support. One convenient solution is for theprocessor 210 to be a drop-in replacement for a processor that maypresently be on a vehicle telematics device. With sufficientmodification to the processor 210, there may not be a need for theseparate security chip 215.

In one embodiment, the vehicle telematics device 110 can use a cellularradio Secure Socket interface (e.g., HTTPS). This embodiment isdependent on which cellular radios and which radio firmware (e.g., whichtype of mobile communications device 116) are deployed in the vehicletelematics device 110. This embodiment is limited to cellular-onlysolutions without a dial-up network (DUN) (e.g., mobile data terminal(MDT) interface).

In one embodiment, the hardware security chip 215 supports cryptographickey generation. Accordingly, private encryption key insertion into thevehicle telematics device 110 is not required to take place offline atthe factory (e.g., not required to take place online while the vehicletelematic system 100 is active). The security chip 215 can supportsecure storage of cryptographic keys and authentication certificates.

In one embodiment, the vehicle telematics device 110 includes hardwareto support Bluetooth Low Energy (BLE) radio. Bluetooth communicationcapability enables the telematics device 110 to communicate with otherdevices (e.g., mobile communications device 116) via the Bluetoothwireless technology standard.

In one embodiment, the vehicle telematics device 110 includes level-3physical security to protect against physical attacks. For example, thevehicle telematics device 110 may include at least one of the following:read-out protection, secure boot for authentication of a run-time image,adding authentication to the attention command (ATCmd) interface, and/orencrypting data stored on an external memory device (e.g., flash memorycoupled to the serial peripheral interface (SPI) bus).

Other Embodiments

Although the embodiments have been described in certain specificaspects, many additional modifications and variations would be apparentto those skilled in the art. In particular, any of the various processesdescribed herein can be performed in alternative sequences and/or inparallel (on the same or on different computing devices) in order toachieve similar results in a manner that is more appropriate to therequirements of a specific application. It is therefore to be understoodthat the embodiments can be practiced otherwise than specificallydescribed without departing from the scope and spirit. Thus, theembodiments should be considered in all respects as illustrative and notrestrictive. It will be evident to the person skilled in the art tofreely combine several or all of the embodiments discussed here asdeemed suitable for a specific application. Throughout this disclosure,terms like “advantageous”, “exemplary” or “preferred” indicate elementsor dimensions that are particularly suitable (but not essential) to anembodiment, and that may be modified wherever deemed suitable by theskilled person, except where expressly required.

While certain exemplary embodiments have been described and shown in theaccompanying drawings, it is to be understood that such embodiments aremerely illustrative of and not restrictive on the broad disclosure, andthat the embodiments not be limited to the specific constructions andarrangements shown and described, since various other modifications mayoccur to those ordinarily skilled in the art.

When implemented in software, the elements of the embodiments areessentially the code segments to perform the necessary tasks. Theprogram or code segments can be stored in a processor readable medium ortransmitted by a computer data signal embodied in a carrier wave over atransmission medium or communication link. The “processor readablemedium” may include any medium that can store or transfer information.Examples of the processor readable medium include an electronic circuit,a semiconductor memory device, a read only memory (ROM), a flash memory,an erasable programmable read only memory (EPROM), a floppy diskette, aCD-ROM, an optical disk, a hard disk, a fiber optic medium, a radiofrequency (RF) link, etc. The computer data signal may include anysignal that can propagate over a transmission medium such as electronicnetwork channels, optical fibers, air, electromagnetic, RF links, etc.The code segments may be downloaded via computer networks such as theInternet, Intranet, etc.

Conclusion

While this specification includes many specifics, these should not beconstrued as limitations on the scope of the disclosure or of what maybe claimed, but rather as descriptions of features specific toparticular implementations of the disclosure. Certain features that aredescribed in this specification in the context of separateimplementations may also be implemented in combination in a singleimplementation. Conversely, various features that are described in thecontext of a single implementation may also be implemented in multipleimplementations, separately or in sub-combination. Moreover, althoughfeatures may be described herein as acting in certain combinations andeven initially claimed as such, one or more features from a claimedcombination may in some cases be excised from the combination, and theclaimed combination may be directed to a sub-combination or variationsof a sub-combination. While embodiments have been particularlydescribed, they should not be construed as limited by such embodiments,but rather construed according to the claims included herein.

What is claimed is:
 1. A vehicle telematics device, comprising: aprocessor; a memory coupled to the processor and storing a vehicletelematics application; and a security chip coupled to the processor andthe memory, wherein the security chip is configured to support aTransport Layer Security (TLS) stack.
 2. The vehicle telematics deviceof claim 1, wherein: the memory is sufficient to handle operations ofthe Transport Layer Security (TLS) stack.
 3. The vehicle telematicsdevice of claim 2, wherein: the memory includes at least 30 kilobytes ofrandom access memory (RAM) and 100 kilobytes of flash memory.
 4. Thevehicle telematics device of claim 1, wherein: the security chip cangenerate and securely store a cryptographic key.
 5. The vehicletelematics device of claim 1, further comprising: a communicationsinterface coupled to the processor and to a data bus of a vehicle. 6.The vehicle telematics device of claim 5, further comprising: one ormore sensor devices coupled to the data bus, capable of measuring sensordata regarding the vehicle, and configured to store the sensor data inthe memory.
 7. The vehicle telematics device of claim 1, wherein: thevehicle telematics device can communicate with a customer server; andthe security chip can transmit encrypted data to the customer server viaa Transmission Control Protocol (TCP)/Transport Layer Security (TLS)security session.
 8. The vehicle telematics device of claim 1, wherein:the vehicle telematics device can communicate with a mobilecommunications device; and the security chip can apply Short MessageService (SMS) authentication via challenge-response authentication withthe mobile communications device.
 9. The vehicle telematics device ofclaim 1, wherein: the vehicle telematics device can communicate with amaintenance server; and the security chip can transmit encrypted data tothe maintenance server via a Transmission Control Protocol(TCP)/Transport Layer Security (TLS) security session.
 10. The vehicletelematics device of claim 1, wherein: the vehicle telematics device cancommunicate with a certificate authority; and the security chip isconfigured to receive a signed certificate authority certificateauthority certificate from the certificate authority.
 11. A vehicletelematics system, comprising: a vehicle telematics device, including aprocessor, a memory coupled to the processor and storing a vehicletelematics application, and a security chip coupled to the processor andthe memory, wherein the security chip is configured to support aTransport Layer Security (TLS) stack.
 12. The vehicle telematics systemof claim 11, wherein: the memory is sufficient to handle operations ofthe Transport Layer Security (TLS) stack.
 13. The vehicle telematicssystem of claim 12, wherein: the memory includes at least 30 kilobytesof random access memory (RAM) and 100 kilobytes of flash memory.
 14. Thevehicle telematics system of claim 11, wherein: the security chip cangenerate and securely store a cryptographic key.
 15. The vehicletelematics system of claim 11, wherein: the vehicle telematics devicefurther includes a communications interface coupled to the processor andto a data bus of a vehicle.
 16. The vehicle telematics system of claim15, wherein: the vehicle telematics device further includes one or moresensor devices coupled to the data bus, capable of measuring sensor dataregarding the vehicle, and configured to store the sensor data in thememory.
 17. The vehicle telematics system of claim 11, furthercomprising: a customer server in communication with the vehicletelematics device, wherein the security chip can transmit encrypted datato the customer server via a Transmission Control Protocol(TCP)/Transport Layer Security (TLS) security session.
 18. The vehicletelematics system of claim 11, further comprising: a mobilecommunications device in communication with the vehicle telematicsdevice, wherein the security chip can apply Short Message Service (SMS)authentication via challenge-response authentication with the mobilecommunications device.
 19. The vehicle telematics system of claim 11,further comprising: a maintenance server in communication with thevehicle telematics device, wherein the security chip can transmitencrypted data to the maintenance server via a Transmission ControlProtocol (TCP)/Transport Layer Security (TLS) security session.
 20. Thevehicle telematics system of claim 11, further comprising: a certificateauthority in communication with the vehicle telematics device, whereinthe security chip is configured to receive a signed certificateauthority certificate authority certificate from the certificateauthority.